“Avalon” is the code name for the presentation subsystem in Microsoft's Longhorn operating system. Avalon provides the foundation for building applications and high fidelity experiences in Longhorn, blending together application UI, documents, and media content, while exploiting the full power of a computer. The Avalon functionality extends to the support for Tablet and other forms of input, a more modern imaging and printing pipeline, accessibility and UI automation infrastructure, data-driven UI and visualization, as well as the integration points for weaving the application experience into the Windows shell.
Avalon enables not only richer control design and development, but it also relies heavily on a vector-based system instead of the more common pixel-based one. Avalon also introduces a new programming model known as XAML (Extensible Application Markup Language) which presents a new way of designing application user interfaces.
To provide flexibilities in this new presentation subsystem, it is desirable to provide support for so-called legacy applications which are pixel-based. Doing so, however, involves reconciling Avalon's processing paradigm with that of the legacy systems.
As an example, consider the following. Sometimes when a legacy application or a device driver interface (DDI) processes a document, it creates primitives that describe objects contained in the document and, because of past software or hardware limitations, those primitives are further processed into less complex (but more numerous) primitives. For example, the graphical component of the Microsoft Windows graphical environment is the graphics device interface or GDI. GDI communicates between the application and the device driver, which performs the hardware-specific functions that generate output. By acting as a buffer between applications and output devices, GDI presents a device-independent view of the world for the application while interacting in a device-dependent format with the device.
In the GDI environment are two working spaces—the logical and the physical. Logical space is inhabited by applications; it is the “ideal” world in which all colors are available, all fonts scale, and output resolution is phenomenal. Physical space, on the other hand, is the real world of devices, with limited color, strange output formats, and differing drawing capabilities. In Windows, an application does not need to understand the quirkiness of a new device. Rather, GDI code works on the new device if the device has a device driver.
GDI concepts mapped between the logical and the physical are objects (pens, brushes, fonts, palettes, and bitmaps), output primitives, and coordinates. For purposes of the present discussion, consider only output primitives which are generated by the application. Output primitives are passed as “logical” requests to the device driver, which draws the primitive to the best of its ability and resolution. If the driver cannot handle a certain primitive—for example, it cannot draw an ellipse—GDI simulates the operation. For an Ellipse call then, GDI calculates a polygon that represents a digitized ellipse. The resulting polygon can then be simulated as a polyline and a series of scanline fills if the device cannot draw polygons itself. The application, though, does not care what system component does the actual work; the primitive gets drawn.
Hence, one of the manifestations of GDI (or GDI+) is that complex primitives (such as the ellipse primitive created by the application) can get processed into many additional primitives that attempt to provide the complex primitive.
In some instances, such as in the case of a gradient, multiple strips of adjoining path vector data with color information will be generated to provide a gradient. In instances where an image is concerned, an image will be sent as a banded physical image through a series of DDI calls.
Because Avalon is pixel-agnostic, so-to-speak, these past or legacy processing approaches, which attempt to break down data with an eye to pixel-efficient processing, create problems in the Avalon system not only from the standpoint of data bloating (creating additional data which is not as efficiently processed in Avalon), but from the standpoint of creating visually-discernable anomalies in the final rendered product. Specifically, in the gradient example which utilizes multiple strips of vector path data, noticeable seams are produced at the strip boundaries. In the case of banded image processing, Avalon's anti-aliasing processing produces noticeable seams when the banded images are rendered.
Accordingly, this invention arose out of concerns associated with providing support for legacy applications in a manner that reduces the occurrences of visually discernable anomalies.